home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1993 July / InfoMagic USENET CD-ROM July 1993.ISO / sources / std_unix / archive / text0068.txt < prev    next >
Encoding:
Text File  |  1993-07-06  |  2.0 KB  |  40 lines
  1. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  2.  
  3. In article <1ttr4kINNdc1@rodan.UU.NET> wanish@kgnvmc.VNET.IBM.COM writes:
  4. > The requirements on a Conforming POSIX.1 Implementation shall not
  5. > be changed.
  6. > ...
  7. >* Purpose of Proposed Standard (Revision)
  8. > To enable implementations and applications to claim conformance, and
  9. > profiles to require conformance, to meaningful subsets of features
  10. > and functionality defined by 1003.1, without changing the
  11. > requirements on Conforming 1003.1 Implementations and Applications, ...
  12.  
  13. The primary goal of POSIX.1 was to provide a portable platform that
  14. significant applications programming in a UNIX environment could rely on.
  15. When we considered "subsetting", it was fairly obvious that it ran counter
  16. to this overriding goal.
  17.  
  18. Another serious drawback to this proposal is that it envisions keeping
  19. all the weird "warts" in the specification, for example what an
  20. interrupted I/O system call returns, atomic pipe buffering, etc.
  21. The only reason these warts are present in POSIX.1 is that we had to
  22. accommodate demands from vendors who already had poorly engineered
  23. existing practice in these areas.  If one were to do a proper job of
  24. specifying minimal, modularized system functionality, certainly such
  25. abominations as the signal mechanism should not be present in the
  26. final design.  While UNIX originally embodied many good ideas, it also
  27. missed on a few significant points, and during commercialization it has
  28. acquired a slew of additional misfeatures.  It would be a severe
  29. disservice to future system evolution to cast such attributes in stone
  30. in the "minimal module" specifications.  I think a MUCH better approach
  31. would be to engineer a new set of specifications for this project,
  32. dropping literal POSIX.1 compatibility as unduly constraining.  Of
  33. course, it would be best if the new specs could be reasonably
  34. implemented on existing POSIX.1-conformant systems, but that is not
  35. the same goal as stated in the PAR.
  36.  
  37.  
  38. Volume-Number: Volume 31, Number 71
  39.  
  40.